GuardDutyの検出結果をFirehose経由でDatadogに転送してみた

GuardDutyの検出結果をFirehose経由でDatadogに転送してみた

GuardDutyの検知ログ、Datadog Logsへの集約を サードパーティへのデータ配信をサポートしたFirehose で設定してみました。
Clock Icon2020.08.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSチームのすずきです。

AWSが提供する脅威検知サービス「GuardDuty」、 その検出結果を サードパーティへのデータ配信をサポートした 「Kinesis Data Firehose」 を利用して 「Datadog Logs」に転送、集約管理を試す機会がありましたので紹介させていただきます。

AWS設定

GuardDuty

「GuardDuty の有効化」のみ実施しました。

Firehose

データ配信先として「Datadog Logs」を設定した 配信ストリームを利用しました。

EventBridge

GuardDuty の 検出結果を Firehose に転送するルールを新規に作成しました。

サービスごとの事前定義パターンを利用し、以下設定を行いました。

  • サービスプロバイダ: 「AWS」
  • サービス名 : 「GuardDuty」
  • イベンドタイプ: 「GuardDuty Findng」
  • ターゲット: 「Firehose配信ストリーム」
  • ストリーム: 事前にDatadog Logs 転送設定を実施したストリームを指定

GuardDutyサンプル

GuardDuty の検出結果のサンプルを生成します。

Datadog 設定

サンプルログ確認

GuardDuty のログは、EventBridge、Firehose を経由して、5分前後でDatadog 上で確認可能になります。

パイプライン

ログ処理を行うパイプラインを設定します。

GuardDuty用として用意された設定を「Browse Pipeline Library」より選択、複製して利用しました。

2020年8月時点では Firehose経由で転送されたGurdDutyログが処理対象外とならないフィルタ設定が存在します。 GuardDuty用のパイプライン設定の複製時、フィルタ設定を「source:guardduty」→「source:aws」と変更しました。

パイプライン設定後、「GuardDutyサンプル」を再実行します。 5分程度経過した後、パイプラインにより加工されたログが Datadog Logs 上に表示されます。

Facet設定

フィルタ、絞り込み対象として利用するログ項目を指定します。

以下の設定を「Add Facet」で追加しました。

Facet 内容
@account AWSアカウント番号
@region AWSリージョン
@detail.severity GuardDutyの重要度
@detail.service.serviceName ログ識別用
@evt.name GuardDuty 結果タイプ
@title GuardDuty 結果詳細

設定後「GuardDutyサンプル」を再実行、5分待機します。

指定した項目による絞り込みが可能となっている事を確認します。

フィルタ設定

パイプラインのフィルタ設定に「@detail.service.serviceName:guardduty」を追加、 GuardDuty ログ専用のパイプラインとして機能するように設定しました。

ログレベル設定

Category Processor

GuardDuty ログに含まれる「severity」の値は 0~10の範囲で、高い値が重度の問題である事を示す仕様です。

Datadog Logs上でのログレベル、ステータスの識別を可能にするため、 GuardDuty ログ用のパイプラインに「Processor」を追加、GuardDuty 重要度を示す数値を 一般的なSyslog の Severity に変換します。

  • Target category attribute: severity_syslog
  • Poplate category (GuardDuty Severity値 -> severity_syslog)変換
MATCHING QUERY(GuardDuty Severity) GuardDuty重要度 severity_syslog
@detail.severity:[7 TO 8.9] High Error
@detail.severity:[4 TO 6.9] Medium Warning
@detail.severity:[1 TO 3.9] Low Notice
@detail.severity:[9 TO 10] (予約) Critical
@detail.severity:[0 TO 0.9] (予約) Informational
- - Emergency
- - Alert
- - Debug

Status Remapper

Category Processor で 変換した、「severity_syslog」を Datadog Logs のログステータスに反映させる「Processor」設定を追加します。

パイプライン動作確認

以下のGuardDuty用パイプライン設定後、「GuardDutyサンプル」を再実行しました。

  • FILTERS
  • Category Processor
  • Status Remapper

GuardDutyの重要度が Datadog Logsの ステータスに反映、色分け表示が可能になりました。

費用

GuardDutyの検出イベント、1件5KBのログが 月間 1000 ~ 1000000 件 発生する想定で、 Datadog Logs と Firehose の料金を試算してみました。

ログ件数(月間) Datadog(件数) Datadog(容量) Firehose(容量) 費用合計(Datadog+AWS)
1000 $0.003 $0.001 $0.000 $0.003
10000 $0.026 $0.005 $0.002 $0.032
100000 $0.255 $0.050 $0.018 $0.323
1000000 $2.550 $0.500 $0.180 $3.230

GuardDutyの検出イベントログのDatadog転送、多くの環境では低コストでの利用が可能と思われます。

まとめ

GuardDuty と Datadog Logs の連携、これまでも Lambda関数を利用する事で実現可能でしたが、 Firehoseのアップデートにより、コード実装なく利用することが可能になりました。

Datadog を利用する事で、柔軟なアラート設定や Slack などチャット通知なども実現可能です。 GuardDuty のより効率的な利用を実現するツール Datadog Log、その連携手段としてFirehose をぜひお試しください。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.